Subject: DLSw transport connection failure issue.

From: Mark Duffy (x2418) <[email-masked]>
Date: Fri, 16 Sep 94 16:52:37 EDT

This note describes a problem we have experienced regarding TCP
connection failures between DLSws.  We suggest several possible fixes
for the problem, one of which would be facilitated by assigning a new
SSP message type.

We would also like to hear about other implementors' experiences or
opinions in this area.

DESCRIPTION OF THE PROBLEM

The problem can occur between two DLSws whenever one of them goes down
or otherwise becomes unreachable by the other.  If the remaining one has
no messages to send, it may not realize that the transport connection
has failed.  However, all circuits using that transport connection will
be unusable because they will never receive any more SSP messages.  The
circuits will be stuck in whatever state, e.g CONNECTED, and so no
further connection attempts would be made.

When the partner DLSw comes back up and attempts to re-establish the TCP
connections, that will bring down the "dangling" ones and cause all the
DLSw circuits to be cleared so that things may start up again.  However,
this may not occur for an extended period of time.  We feel that a
broken transport connection should be detected fairly quickly so that
sessions using it may be brought down (and possibly re-established via
an alternate DLSw router).

SOLUTIONS TO THE PROBLEM

Sending "keepalives" to the remote DLSw periodically would detect a
transport failure because the transport layer acknowledgement would
never be received.  The keepalives should be sent in such a way that
they are transparent within the data stream.  That is, that any remote
DLSw will automatically discard them without being specifically enhanced
to do so.

One way to accomplish this would be to send keepalives within the
transport level.  This would be transparent to Data Link Switching, but
would detect affected transport connections in a timely manner, so that
DLSw could be notified.  A benefit of this approach is that some
transport implementations may already provide this feature.  A drawback
of this approach is that there may exist transport protocols (but not
TCP) with which it is not possible to send keepalives that are
transparent in the data stream.

A second approach would be to send keepalives at the DLSw level.  Since
no DLSw-level response would be required, this would best be implemented
by sending some short SSP message that would automatically be discarded
by the remote DLSw with minimal processing.  This could be some
already-defined message type sent with such parameters that it would
have to be discarded (e.g. INFOFRAME for non-existent circuit ID).
However, it would be much cleaner and safer to allocate a new SSP
message type, e.g. NULL_MESSAGE, which any DLSw would automatically
discard.

Since either approach to sending keepalives would be designed to work
transparently with any remote DLSw, this can be mainly a matter of
implementation that is outside the DLSw specification.  However, the
second approach would be best served by assigning a new null SSP message
type within the DLSw spec.

Mark Duffy
Bolt Beranek and Newman (BBN)